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(57) ABSTRACT 

In a job transferring method of sending a request from a first 
computer to a second computer so as to cause the second 
computer to register and execute a job, the request is created 
so that it can include a plurality of scripts, the script being 
an aggregation of a plurality of commands. For example, the 
first computer creates a request data stream that includes the 
content of the plurality of scripts, then sending the created 
request data stream to the second computer. Moreover, the 
second computer extracts the content of the plurality of 
scripts included in the request data stream and stores the 
content as a script file for each script, then executing a script 
to be executed first of the plurality of scripts. 



COMMUNICATION SEQUENCE OF JOB-INFORMATION ACQUISITION 
<SERVER> <CLIENT> 



accept 0^41 ■( 



412 4 } 3 



read () 

write () SERIES = 1 
read ()>-<^4"|4 
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read 0-^423 



424 
$ 
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close () 
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FIG. 1 



ENTIRE SYSTEM CONFIGURATION 





102 




103 



1 



120 




01/26/2004, EAST Version: 1.4.1 



Patent Application Publication Jul. 31, 2003 Sheet 2 of 12 US 2003/0145049 Al 



C\J 

CD 

LL 




^1- 

o 

CM 



CO 
O 
CM 



A 
\- 
Z 
UJ 

_l 

o 

V 



CO 



S 

DC 

b 

CO 
CO 



LU 






\— 






RA 




_t 
UJ 






o 




CD 


z 


z 


Z) 


< 


UJ 


CO 


o 



UJ 



UJ 

CD 



01/26/2004, EAST Version: 1.4.1 



Patent Application Publication Jul. 31, 2003 Sheet 3 of 12 US 2003/0145049 Al 



FIG. 3 

COMMUNICATION SEQUENCE OF JOB REGISTRATION, STATE ALTERATION, 
DELETION REQUEST, QUEUE ENUMERATION 

<SERVER> <CLIENT> 



accept () ' 


—311 


read () >_r 


-312 


write () 


-313 


close () - 


-314 



connect () 
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write 0— 
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read () ^ 
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close () 
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FIG. 4 

COMMUNICATION SEQUENCE OF JOB-INFORMATION ACQUISITION 
<SERVER> <CLIENT> 



accept 0 — 411 



412 4 f 



read () 

write () SERIES = 1 
read ()— 414 
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write () SERIES = 1 
read 0—416 
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write () SERIES = 0 



close 0—418 



401 



connect 0-^421 
write 0^422 



read 0—423 
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write () SERIES = 1 
426 



read 0—425 



write (} SERIES = 1 



read 0—427 
close () —428 
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FIG. 5A 
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< RESPONSE DATA STREAM > 
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FIG. 8A qsub [(-t TRANSFERSOURCEFILENAME(=TRANSFERTARGETFLENAME)) - J 
FIG. 8B qsub ojejest -q p_oje -t M test01 . jcl = script (scripta)" 

FIG. 8C CASE OF TRANSFERRING TWO 

qsub ojejest -q p_oje -t "testOI . jcl = script (scripts)" -t 
testCN . jcl2 = script (scriptb) -start "script (scriptb)" 



01/26/2004, EAST Version: 1.4.1 



Patent Application Publication 



Jul. 31, 2003 Sheet 5 of 12 



US 2003/0145049 Al 



FIG. 6 

EXAMPLE OF SCRIPT TRANSFERRING STREAM 

SENDSCRIPT = yes ; 
SCRIPTSTART = script / scriptb ; 
SCRIPTNAME = script / scripta ; 
SCRIPTLINES = 4 ; 
SCRIPTBODY = # ! / bin / ksh ; 
SCRIPTBODY = xxx ; 
SCRIPTBODY = xxx ; 
SCRIPTBODY = xxx ; 
SUBSET = END 

SCRIPTNAME = script / scriptb ; 
SCRIPTLINES = 4 ; 
SCRIPTBODY = # ! / bin / ksh ; 
SCRIPTBODY = xxx; 
SCRIPTBODY = xxx ; 
SCRIPTBODY = xxx; 
SUBSET = END 
(NULL) 



01/26/2004, EAST Version: 1.4.1 



Patent Application Publication Jul. 31, 2003 Sheet 6 of 12 US 2003/0145049 Al 



FIG. 7 

CONTENT EXAMPLE OF JOB PARAMETER DEFINITION FILE 
[to] 

E-Time= 1-1440 

ClientHost=HOST NAME 

MessageUserName = USER NAME 

MessageHos(Name=COMPUTER NAME 

StaifTime=TIMEAND DATE OF STARTING JOB-EXECUTION 

Interactive = YES/NO 

JobTrans=YES/NO 

[Trans] 

TransFileNumber=THE NUMBER OF TRANSFER FILES 
TransSourceFile 1 = TRANSFER SOURCE FILE NAME1 
TransTargetRle 1 = TRANSFER TARGET FILE NAME1 
TransSourceFile 2 = TRANSFER SOURCE FILE NAME2 
TransTargelFile 2 = TRANSFER TARGET FILE NAME2 



TransSourceFile n= TRANSFER SOURCE FILE NAME n(n IS 1 ~ THE NUMBER OF 
TRANSFER FILES) (ESSENTIAL BY THE NUMBER OF TRANSFER FILES) 
TransTargetFile n= TRANSFER TARGET FILE NAME n(n IS 1 -THE NUMBER OF 
TRANSFER FILES) (ESSENTIAL BY THE NUMBER OF TRANSFER FILES) 
[Command] 

FilePath= COMMAND (ESSENTIAL) 
CommandUne = PARAMETER 
CurrentPalh = OPERATION FOLDER NAME 
ScriptStart= TRANSFER TARGET FILENAME2 



[Variable] 
XXX-XXX 
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FIG. 10 



SCRIPT-EXTRACTION PROCESSING ROUTINE IN 
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FIG. 11 
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METHOD AND SYSTEM FOR TRANSFERRING 
JOB BETWEEN COMPUTERS 

BACKGROUND OF THE INVENTION 

[0001] The present invention relates to a method and a 
system for transferring a job between computers. In particu- 
lar, it relates to a job transferring method and its system that 
make it possible to transfer a plurality of scripts. 

[0002] Since conventionally, there has been known the 
following job transferring method: One computer transfers a 
batch job to another computer, and another computer 
executes the batch job and returns the result of the execution 
back to the computer of the job transfer source. The batch 
job is useful at the time when a computer not only wishes to 
execute one business application but also wishes to execute 
another business application simultaneously in the mean- 
time. When a job (i.e., business application software) is 
transferred to the computer, the job is once registered in a 
queue within the computer. At this point in time, it becomes 
possible to receive transfer of the next job (i.e., another 
business application). The system fetches and executes, in 
sequence, the jobs registered in the queue. The operation of 
such a batch job is absolutely necessary for implementing 
the setting and the automatization of a business application 
such as a total accumulating processing of data to be 
executed on a daily or monthly basis. 

[0003] As the job transferring method as described above, 
there has been known various types of methods. When 
classified roughly, there exists the following three types: In 
the job transferring method of the first type, one computer 
simply provides a job-executing instruction to another com- 
puter and performs nothing else. Transfer of a script, which 
will be described later, is not performed. The computer that 
had issued the job -executing instruction receives the execu- 
tion state and result of the instructed job as status informa- 
tion sent from the computer that has executed the job. In the 
job transferring method of the second type, one script is 
transferred immediately before the one computer provides 
the job-executing instruction to another computer. In this 
case, the execution result of the instructed job is returned as 
a single result file. The script is an aggregation of a plurality 
of commands provided to the computer executing the job. 
Some script is set so that it is capable of performing a simple 
control such as a conditional branch. The use of the script 
makes it possible to perform, with a one-time input of the 
job, a sequence of executions including the plurality of 
commands. In the job transferring method of the third type, 
a script file, aside from the job-executing instruction, has 
been transferred in advance as a file transfer or file distri- 
bution form, and the job -executing instruction is performed 
later. 

[0004] The job transferring methods of the first and second 
types mentioned above will be understood for example by 
qsub commands explained in "Submitting a NQS Batch 
Job", by Institute for Scientific Computation, http://www.is- 
c.edu/isc/nqs/qsub -main.html. 

SUMMARY OF THE INVENTION 

[0005] There are many cases where, in the job transfer, it 
is desirable to make the computer of the job transfer target 
call up another script from one script and execute another 
script. In this occasion, it turns out that a single job includes 



a plurality of scripts. None of the above-described conven- 
tional methods of the first to the third types, however, has 
succeeded in performing the executing instruction of the 
plurality of scripts simultaneously with the performance of 
transferring the plurality of scripts. This situation makes it 
unavoidable to employ a method in which the plurality of 
scripts have been transferred in advance and, at the time of 
the execution, only the job-executing instruction is per- 
formed. This method is simply a combination of the above- 
described conventional technique of the third type and that 
of the first type. In the method of this combination type, 
however, it is required to continue managing the script file 
all the while until the job -executing command has been sent. 
On account of this, the version management thereof and so 
on become complicated. This condition will give rise to the 
following problems: If the script file is forgotten to be 
transferred, a wrong job may be executed. Otherwise, imme- 
diately before the execution of a job, a related script has been 
created or modified already and, as a result, it becomes 
impossible to execute the job. 

[0006] In view of the above-described problems in the 
conventional techniques, it is an object of the present 
invention to provide a job transferring method and its system 
that, in the job transferring method between computers, 
allow the job -executing instruction to be performed simul- 
taneously with the performance of transferring the plurality 
of scripts. 

[0007] In order to accomplish the above-described object, 
the present invention is characterized by the following: Ajob 
transferring method of sending a request from a first com- 
puter to a second computer so as to cause the second 
computer to register and execute a job, wherein a plurality 
of scripts are included in the above-mentioned request, the 
script being an aggregation of a plurality of commands. 

[0008] Also, the present invention is characterized by the 
following: Ajob transferring method of sending a request 
from a first computer to a second computer so as to cause a 
job to be registered and executed, including a step of 
creating, by the first computer, a request data stream includ- 
ing content of a plurality of scripts, and a step of sending, by 
the first computer, the created request data stream from the 
first computer to the second computer. 

[0009] Also, the present invention is characterized by the 
following: A job transferring method of sending a request 
from a first computer to a second computer so as to cause a 
job to be registered and executed, including a step of 
receiving, by the second computer, a request data stream 
sent from the first computer, the request data stream includ- 
ing content of a plurality of scripts, a step of extracting, by 
the second computer, the content of the plurality of scripts 
in the received request data stream and storing the content of 
the plurality of scripts as a script file for each script, and a 
step of executing, by the second computer, a script to be 
executed first of the plurality of scripts. 

[0010] Also, the present invention is characterized by the 
following: A job transferring method of sending a request 
from a first computer to a second computer so as to cause a 
job to be registered and executed, including a step of 
creating, by the first computer, a request data stream includ- 
ing content of a plurality of scripts, a step of sending the 
created request data stream from the first computer to the 
second computer, a step of extracting, by the second com- 
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puter, the content of the plurality of scripts in the request 
data stream and storing the content of the plurality of scripts 
as a script file for each script, and a step of executing, by the 
second computer, a script to be executed first of the plurality 
of scripts. 

[0011] Also, the present invention is characterized by the 
following: A job transferring method of sending a request 
from a first computer to a second computer so as to cause a 
job to be registered and executed, including a step of 
creating, by the first computer, a request data stream, the 
request data stream including content of a plurality of scripts 
and an executing instruction for a script to be executed first 
of the plurality of scripts, a step of sending the created 
request data stream from the first computer to the second 
computer, a step of extracting, by the second computer, the 
content of the plurality of scripts in the request data stream 
and storing the content of the plurality of scripts as a script 
file for each script, and a step of fetching and executing, by 
the second computer, the executing instruction for the script 
to be executed first, the executing instruction being included 
in the request data stream. 

[0012] It is preferable that the above-described request 
data stream should be a text data -formatted stream and, 
utilizing predetermined tags, describe various types of 
parameter information. 

[0013] Moreover, the present invention is characterized by 
the following: A job transferring method of sending a 
request from a first computer to a second computer so as to 
cause a job to be registered and executed, including a step 
of sending, by the second computer, a plurality of result files 
from the second computer to the first computer, the plurality 
of result files being created as a result of the second 
computer's executing the job, and a step of receiving, by the 
first computer, the plurality of result files. 

[0014] Also, the present invention is characterized by the 
following: A job transferring method of sending a request 
from a first computer to a second computer so as to cause a 
job to be registered and executed, including a step of 
creating a response data stream including content of a 
plurality of result files, the plurality of result files being 
created as a result of the second computer's executing the 
job, a step of sending the created response data stream from 
the second computer to the first computer, and a step of 
extracting, by the first computer, the content of the plurality 
of result files in the response data stream and storing the 
content of the plurality of result files for each result file. It 
is preferable that the above -described response data stream 
should be a text data-formatted stream. 

[0015] Also, the present invention is characterized by the 
following: A job transferring system, including a first com- 
puter for sending a second computer a request for causing a 
job to be registered and executed and the second computer 
for receiving the request sent from the first computer so as 
to register and execute the job in accordance with the 
request, wherein a plurality of scripts are included in the 
above-mentioned request, the script being an aggregation of 
a plurality of commands. 

[0016] Also, the present invention is characterized by the 
following: A first computer of a job transfer source in a job 
transferring system that includes the first computer for 
sending a second computer a request for causing a job to be 



registered and executed and the second computer for receiv- 
ing the request sent from the first computer so as to register 
and execute the job in accordance with the request, the first 
computer including means for creating a request data stream 
including content of a plurality of scripts, and means for 
sending the created request data stream to the second 
computer. 

[0017] Also, the present invention is characterized by the 
following: Asecond computer of a job transfer target in a job 
transferring system that includes a first computer for sending 
the second computer a request for causing a job to be 
registered and executed and the second computer for receiv- 
ing the request sent from the first computer so as to register 
and execute the job in accordance with the request, the 
second computer including means for receiving a request 
data stream sent from the first computer, the request data 
stream including content of a plurality of scripts, means for 
extracting the content of the plurality of scripts in the 
received request data stream and storing the content of the 
plurality of scripts as a script file for each script, and means 
for executing a script to be executed first of the plurality of 
scripts. 

[0018] Also, the present invention is characterized by the 
following: A job transferring system, including a first com- 
puter for sending a second computer a request for causing a 
job to be registered and executed and the second computer 
for receiving the request sent from the first computer so as 
to register and execute the job in accordance with the 
request, wherein the first computer includes means for 
creating a request data stream including content of a plu- 
rality of scripts, and means for sending the created request 
data stream from the first computer to the second computer, 
and the second computer includes means for extracting the 
content of the plurality of scripts in the request data stream 
and storing the content of the plurality of scripts as a script 
file for each script, and means for executing a script to be 
executed first of the plurality of scripts. 

[0019] Also, the present invention is characterized by the 
following: A job transferring system, including a first com- 
puter for sending a second computer a request for causing a 
job to be registered and executed and the second computer 
for receiving the request sent from the first computer so as 
to register and execute the job in accordance with the 
request, wherein the first computer includes means for 
creating a request data stream, the request data stream 
including content of a plurality of scripts and an executing 
instruction for a script to be executed first of the plurality of 
scripts, and means for sending the created request data 
stream from the first computer to the second computer, and 
the second computer includes means for extracting the 
content of the plurality of scripts in the request data stream 
and storing the content of the plurality of scripts as a script 
file for each script, and means for fetching and executing the 
executing instruction for the script to be executed first, the 
executing instruction being included in the request data 
stream. 

[0020] It is preferable that the above-described request 
data stream should be a text data-formatted stream and, 
utilizing predetermined tags, describe various types of 
parameter information. 

[0021] Also, the present invention is characterized by the 
following: A job transferring system, including a first com- 
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puter for sending a second computer a request for causing a 
job to be registered and executed and the second computer 
for receiving the request sent from the first computer so as 
to register and execute the job in accordance with the 
request, wherein the second computer includes means for 
sending a plurality of result files from the second computer 
to the first computer, the plurality of result files being created 
as a result of executing the job, and the first computer 
includes means for receiving the plurality of result files. 

[0022] Also, the present invention is characterized by the 
following: A job transferring system, including a first com- 
puter for sending a second computer a request for causing a 
job to be registered and executed and the second computer 
for receiving the request sent from the first computer so as 
to register and execute the job in accordance with the 
request, wherein the second computer includes means for 
creating a response data stream including content of a 
plurality of result files, the plurality of result files being 
created as a result of executing the job, and means for 
sending the created response data stream from the second 
computer to the first computer, and the first computer 
includes means for extracting the content of the plurality of 
result files in the response data stream and storing the 
content of the plurality of result files for each result file. It 
is preferable that the above-described response data stream 
should be a text data-formatted stream. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0023] FIG. 1 is a diagram for illustrating an example of 
the entire configuration of a system to which the job trans- 
ferring method relating to the present invention is applied; 

[0024] FIG. 2 is a diagram for explaining a basic opera- 
tion of a communication protocol between a client and a 
server; 

[0025] FIG. 3 is a diagram for illustrating a concrete 
communication sequence at the time of issuing requests; 

[0026] FIG. 4 is a diagram for illustrating a concrete 
communication sequence at the time of issuing a request for 
job -information acquisition; 

[0027] FIGS. 5A and 5B are diagrams for illustrating 
formats of communication data; 

[0028] FIG, 6 is a diagram for illustrating an example of 
the description of scripts in a request body; 

[0029] FIG. 7 is a diagram for illustrating the content of 
a job parameter definition file; 

[0030] FIGS. 8A, 8B and 8C are diagrams for illustrating 
examples of a job registering command; 

[0031] FIG. 9 is a diagram for illustrating the internal 
configuration of a client and a server relating to a job 
registration and a response to the execution result; 

[0032] FIG. 10 is a flow chart for illustrating the proce- 
dure of a script extraction processing; 

[0033] FIG. 11 is a flow chart for illustrating a processing 
routine (a portion) of an execution managing unit; 

[0034] FIG. 12 is a flow chart for illustrating the proce- 
dure of a job-information GET processing; 



[0035] FIG. 13 is a diagram for illustrating an example of 
a job registration screen and 

[0036] FIG. 14 is a diagram for illustrating an example of 
a job state display. 

DESCRIPTION OF THE EMBODIMENTS 
[0037] Hereinafter, referring to the drawings, the detailed 
explanation will be given concerning an embodiment of the 
present invention. 

[0038] FIG. 1 illustrates an example of the entire configu- 
ration of a system to which the job transferring method 
relating to the present invention is applied. In FIG. 1, 
reference numerals 101-103 denote computers that become 
servers each. Reference numerals 111-114 denote computers 
that become clients each. The servers 101-103 and the 
clients 111-114, which are connected to a network 120, are 
capable of providing/receiving various kinds of information 
among the respective apparatuses. The respective clients 
111-114 are able to carry out the following processing: 
Registering a job into the respective servers 101-103, and 
causing the respective servers to execute the job in a 
batch -processing manner, and then causing the respective 
servers to return the result back to the respective clients. 
Concretely speaking, registering the job means that a pro- 
gram-executing instruction written in a predetermined job 
control language is transferred to a server. At the time of this 
job transfer, a plurality of scripts to be executed on the server 
can be included into the transfer data. This condition makes 
it possible to simultaneously instruct transfer of the plurality 
of scripts and the execution thereof through the job regis- 
tration at a one-time, thereby being capable of causing the 
server to perform complicated processings. Being able to 
transfer the job in being divided into the plurality of scripts 
makes it easier to create or manage the scripts. It is also 
possible to execute the job by creating or modifying the 
scripts immediately before the execution. 

[0039] Platforms (for example, UNIX, a mainframe, or 
Windows NT (i.e., brand name of Microsoft Corporation)) 
that are independent of each other can be used as the 
respective servers and the respective clients. As the clients, 
various types of schemes, for example, a job launcher client 
and a WWW browser client, can be used. Also, it is also 
possible to perform the job registration by using a prede- 
termined API (application program interface) from a variety 
types of user programs. The operations needed for the job 
registration from the client to the server are, for example, an 
operation of inputting a predetermined command or an 
operation of the instruction using a predetermined GUI 
(graphical user interface). The job (request) registered in the 
server is once registered in a queue. The client can display 
the state of the queue by inquiring of the server about the 
state, or can cancel the job registered in the queue. It is 
allowable to provide a server gateway between the client and 
the server. The server gateway carries out the following 
processing: Receiving a variety types of requests (demand) 
from the respective clients, judging to which server the 
respective requests should be transferred, transferring the 
request to the server, receiving and summarizing, as 
response data, the request execution result from the server, 
and returning the response data back to the client of the 
request issue source. 

[0040] FIG. 2 is a diagram for explaining a basic opera- 
tion of a communication protocol between a client and a 
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server. Here, there is illustrated an example where a server 
gateway is provided between the client and the server. 

[0041] The request issuing side is a client 201. In the client 
201, in accordance with the input of the command or the 
instruction using the GUI, a program operates which issues 
various types of requests to a server. The program performs 
the processing in a procedure of connecting the client with 
a user-specified port and of issuing the various types of 
requests and of releasing the connection. As the various 
types of requests that the client issues, there can be men- 
tioned SUBMIT (registration of a job), ALTER (alteration of 
job state), CANCEL (request for deletion of a job), ENUM- 
RATE (enumeration of jobs existing in the queue), GET 
(acquisition of job information), and so on. A text-based 
request data stream referred to as a request block 202 
transfers these requests to a server gateway 203. 

[0042] The server gateway 203 receives the request block 
202 transferred from the respective clients and analyzes the 
request, then judging to which server the request should be 
transferred. Furthermore, the server gateway 203 transfers 
the request to the corresponding server 204 and, receiving 
the execution result transferred from the server 204, creates 
the response data, and then creates a text-based response 
data stream 205 referred to as a response block 205 thereby 
returning the response data back to the client 201 of the 
request issue source. Additionally, the connections between 
these servers/clients are connected/disconnected in a unit of 
the request. Also, the server gateway may be situated on the 
same server as the server body. 

[0043] Incidentally, it is also allowable to establish, using 
the request block 202 and the response block 205, direct 
communications between the client 201 and the server 204 
without providing the server gateway 203. Providing the 
server gateway 203, however, allows a protocol to be 
converted by the server gateway 203, the protocol (the 
further details of which will be explained in FIGS. 3-6) 
resulting from using the request block 202 and the response 
block 205 on the network. This condition makes it possible 
to carry out communications between the server 204 and the 
server gateway 203 with the use of a protocol that has been 
provided to the server 204 since conventionally. Accord- 
ingly, there is no need of supporting a new protocol on the 
side of the server 204. Consequently, it becomes unneces- 
sary to amend the side of the server 204, which is advan- 
tageous and convenient. 

[0044] FIG. 3 illustrates a concrete communication 
sequence at the time when the client issues the following 
requests: The job registration (SUBMIT), the state alteration 
(ALTER), the deletion request (CANCEL) and the queue 
enumeration (ENUMRATE), In accordance with an accept 
instruction, i.e., an accept( ) 311, a server 301 waits for a 
connect request from the client 302. A client 302 issues a 
connect instruction, i.e., a connect( ) 321, thereby establish- 
ing the connection with the server 301. After the connection 
is established, in accordance with a write instruction, i.e., a 
write( ) 322, the client 302 sends a request for any one of the 
above-described job registration (SUBMIT), the state alter- 
ation (ALTER), the deletion request (CANCEL) and the 
queue enumeration (ENUMRATE). In accordance with a 
read instruction, i.e., a read( ) 312, the server 301 receives 
the request and performs the processing in response to the 
request, then returning the result back to the client 302 in 



accordance with a write( ) 313. The client 302 receives the 
result in accordance with a read( ) 323. These reads and 
writes are repeated a plurality of times in correspondence 
with an amount of the data. After these processings, the 
server 301 executes a close, i.e., a close( ) 314 and the client 
302 executes a close, i.e., a close( ) 324, thus terminating the 
communication sequence. 

[0045] FIG. 4 illustrates a concrete communication 
sequence at the time of issuing a request for the job- 
information acquisition (GET). In the acquisition of the job 
information (GET), there are some cases where a large 
amount of data is transmitted/received. Accordingly, the 
communication is executed in such a manner that the 
amount of the data transmitted/received at a time is limited. 
Concretely, the employment of a series tag controls con- 
tinuation of the data and termination of the transmission/ 
reception thereof. Also, in the job -information acquisition 
(GET), it is allowable to provide the server with a filer 
function based on acquisition conditions (the time range, the 
job name, and so on). 

[0046] The explanation will be given below concerning 
the communication sequence of the job-information acqui- 
sition (GET) with the employment of the series tag. In 
accordance with an accept instruction, i.e., an accept( ) 411, 
a server 401 waits for a connect request from the client 402. 
A client 402 issues a connect instruction, i.e., a connect( ) 
421, thereby establishing the connection with the server 401. 
After the connection is established, in accordance with a 
write( ) 422, the client 402 sends a request for a job- 
information acquiring request. In accordance with a read( ) 
412, the server 401 receives the job-information acquiring 
request and prepares job information that is to respond to the 
request. Since the job information that is to respond is a large 
amount of data, with the series=l set in a write( ) 413, a 
portion of the job information is sent to the client 402. 
Although the client 402 receives the portion of the job 
information in accordance with a read( ) 423, the portion of 
the job information has been sent with the series=l set. 
Consequently, the client 402 issues a request for continuing 
to acquire the continued data with the series=l set in a write( 
) 424. The server 401 receives the job -information acquiring 
request in accordance with a read( ) 414 and, in answer to 
the request, sends the continued job information to the client 
402 with series=l set in a write( ) 415. As having been 
described until now, writes and reads (415, 416, 425, 426, . 
. . ) are repeated necessary times with series-1 set. When the 
job information sent from the server 401 becomes final data, 
the server 401 sends the final job information with the 
series-0 set in a write( ) 417. The client 402 receives the job 
information in accordance with a read( ) 427. The reception 
is performed with the series-0 set in the read( ) 427, and 
accordingly the client 402 is able to find that the job 
information is the final data. After these processings, the 
server 401 executes a close, i.e., a close( ) 418 and the client 
402 executes a close, i.e., a close( ) 428, thus terminating the 
communication sequence. 

[0047] FIGS. 5A and 5B illustrate formats of communi- 
cation data that are actually read and written at the time of 
sending the server the respective requests in the communi- 
cation sequence illustrated in FIG. 3 or FIG. 4. FIG. 5A 
illustrates the request data stream (202 in FIG. 2) written 
from the client and read at the server. The request data 
stream includes a header portion 510 and a body portion 
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520. The header portion 510 includes a general header 511 
and a request header 512. The body portion 520 includes a 
request body 521, FIG. 5B illustrates the response data 
stream (205 in FIG. 2) written from the server and read at 
the client. The response data stream includes a header 
portion 530 and a body portion 540. The header portion 530 
includes a general header 531 and a response header 532. 
The body portion 540 includes a response body 541. These 
data are described in a text-based format of "tag name= 
value; 11 . The character codes of the tag name and the 
specified value are all ASCII code. 

[0048] The general headers 511, 531 include general infor- 
mation such as a version of the protocol of the communi- 
cation sequence. The request header 512 includes a character 
string indicating the request toward the server (the job 
registration (SUBMIT), the state alteration (ALTER), the 
deletion request (CANCEL), the queue enumeration 
(ENUMRATE), or the job-information acquisition (GET)), 
and information characteristic of the request such as a length 
of the body portion. The response header 532 includes 
information characteristic of the response such as a length of 
the body portion. The request body 521 includes content of 
the request (for example, in the case of SUBMIT, the name 
of the queue registering the job, the name given to the job, 
the name of a file executed as the job, and so on). The 
response body 541 includes content of the response. 

[0049] In particular, it is possible to describe a plurality of 
scripts in the request body 521. FIG. 6 illustrates an example 
of the description of the scripts in the request body 521. 
SENDS CRIPT-yes; is a declaration that the scripts are 
transferred from this position. SCRIPTS TART-script/ 
scriptb; declares that a script to be executed first is a scriptb, 
SCRIPTNAME-script/scripta; is a file name of a script 
transferred actually, and here the scripta is the file name. 
SCRIPTLINES-4; indicates the line number of content of 
the scripts subsequent thereto. Here, the lines of SCRIPT- 
BODY- . . . ; by the number of 4 lines starting from the line 
next to SCRIPTLINES-4; are the actual content of the 
scripta. SUBSET-END indicates the end of the scripta. In 
much the same way, the scriptb is described next. Repeating 
this allows the plurality of scripts to be described in the 
request body 521. A final (NULL) indicates the end of the 
request data stream transferred. 

[0050] FIG. 7 illustrates a job parameter definition file 
that, in the case where the client is a Windows NT-based 
machine, the client uses when issuing the above-described 
various types of requests. When a job is registered from the 
client to the server, the job parameter definition file of the 
content like this is created and is passed to a command 
analyzing unit (911 in FIG. 9) inside the client, which is 
described later. Then, the command analyzing unit analyzes 
this job parameter definition file, thereby creating the above- 
described request data stream so as to transfer the request 
data stream to the server. 

[0051] The job parameter definition file illustrated in FIG. 
7 is a text-based file of so-called INI file format. Its content 
may be set/edited by an application program for receiving 
the job registration by the user, or can also be set/edited by 
a variety types of text editors. A portion indicated by [Trans] 
within the job parameter definition file is a portion for 
specifying a plurality of files to be transferred. This portion 
allows the plurality of scripts to be included into the transfer 



data. Concretely, the respective scripts are created as one 
script file each, and the script files are specified as the 
transfer files in [Trans]. Incidentally, a unit in which the 
scripts are counted one by one is based on a grammar 
describing the scripts. Consequently, it is also possible to 
describe the plurality of scripts in one script file. In that case, 
it is sufilcient to specify the plurality of script files as the 
transfer files in [Trans], 

[0052] FIGS. 8A, 8B and 8C illustrate examples of a job 
registering command in the case of the UNIX. As illustrated 
in FIG. 8A, a job is registered by a qsub command. At that 
time, the specification is carried out to the operand as "-t 
transfer source file name=transfer target file name" ("trans- 
fer target file name" need not be specified), thereby making 
it possible to transfer the specified file. This allows a script 
file to be transferred. FIG. 8B illustrates a concrete example 
where the script file is transferred by the qsub command. 
Here, it is instructed to store testOl.jcl, i.e., a script file on 
the UNIX, into the transfer target in the name of script 
(scripta). FIG. 8C illustrates an example where two script 
files are transferred. TestOl.jcl, i.e., the script file on the 
UNIX, is stored into the transfer target in the name of script 
(scripta), and testOl jcl2, i.e., a script file on the UNIX, is 
stored into the transfer target in the name of script (scriptb). 
A declaration of — start "script (scriptb)" specifies the script 
(scriptb) as a script file to be executed first. 

[0053] FIG. 9 is a diagram for illustrating the internal 
configuration of a client and a server relating to a job 
registration and a response to the execution result. A client 
910 includes the following: The command analyzing unit 
911, a registering unit 912, and a state display unit 913. A 
server 920 includes the following: A request analyzing unit 
921, a job queue managing unit 922, a job queue 923, an 
execution managing unit 924, an executing unit 925, a script 
file storing unit 926, and an execution-result storing unit 
927. 

[0054] Based on the instruction from the user, the com- 
mand analyzing unit 911 creates the request data stream. If, 
for example, the client 910 is the Windows NT-based 
machine, the job parameter definition file as explained in 
FIG. 7 is created and passed to the command analyzing unit 
911. Then, in accordance with the content of the job param- 
eter definition file, the command analyzing unit 911 creates 
the request data stream as explained in FIGS. 5A and 6. If 
the client 910 is the UNIX-based machine, the qsub com- 
mand as explained in FIGS. 8A to 8C is inputted into the 
command analyzing unit 911. Then, in accordance with the 
specification by the qsub command, the command analyzing 
unit 911 creates the request data stream as explained in 
FIGS. 5A and 6. In either case, it is possible to perform the 
job registration including the plurality of scripts. 

[0055] The request data stream created by the command 
analyzing unit 911 is inputted through the registering unit 
912 into the request analyzing unit 921 situated in the server 
920. The very protocol of the data transmission/reception at 
this time has been explained already in FIGS. 2 to 6. The 
request analyzing unit 921 in the server 920 receives and 
analyzes the request data stream. If a script is included in the 
request data stream, the request analyzing unit extracts the 
script, storing it into the script file storing unit 926. On this 
occasion, if a plurality of scripts are included in the request 
data stream, the request analyzing unit stores the respective 
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scripts into the script file storing unit 926 in such a manner 
that the respective scripts are filed as one script file each. For 
instance, in the case where the request data stream as 
illustrated in FIG. 6 has been inputted, the scripts therein are 
stored into the script file storing unit 926 as the two script 
files of the scrip ta and the scrip tb. Incidentally, it may be 
considered that the server 920 in FIG. 9 has the function of 
the server gateway as well that is illustrated in FIG. 2. 

[0056] FIG. 10 illustrates the procedure of the script 
extraction processing, which is a portion of the analysis 
processing of the request data stream in the request analyz- 
ing unit 921 and is executed when SENDSCRIPT»yes; is 
detected. When SENDSCRIPT=yes; is detected, at a step 
1001, it is judged whether or not the next line is a line of 
SCRIPTNAME=. If the next line is the line of SCRIPT- 
NAME«, at a step 1002, a script file with a specified name 
is created under a request-by-request node in the script file 
storing unit 926. Next, at a step 1003, SCRIPTLINES that 
is subsequent to the line of SCRIPTNAME=is read out, and 
lines of SCRIPTBODY by the number of the read lines are 
read out and are written into the above-described script file. 
The script file is closed at a step 1004 and, going back to the 
step 1001 as indicated by an arrow, it is judged whether or 
not there exists the next SCRIPTNAME=. Hereinafter, the 
processing similar to the above-mentioned processing is 
repeated, thereby extracting all the scripts included in the 
request data stream and writing them into the respective 
script files of their own. This operation stores, into the script 
file storing unit 926, all the scripts included in the request 
data stream that has been sent. 

[0057] Now, going back to FIG. 9, the request analyzing 
unit 921 in the server 920, along with the script extraction 
as described above, registers a job into the job queue 923 
through the job queue managing unit 922. If the request data 
stream sent from the client includes no script and is a request 
for executing one command (program file) alone, an execut- 
ing instruction for the command is registered into the job 
queue 923. Also, if the request data stream sent from the 
client includes one script, an executing instruction for the 
one script is registered into the job queue 923. If the request 
data stream sent from the client includes a plurality of 
scripts, an executing instruction for a script (hereinafter, 
referred to as a main script) to be executed first of those 
scripts is registered into the job queue 923. 

[0058] Additionally, in the request data stream that the 
client 910 creates and sends to the server 920, a file name to 
be executed first in the server is specified. Accordingly, if the 
request data stream includes no script and is the request for 
executing one command (program file) alone, a file name of 
the one command should have been specified as the file 
name to be executed first in the request data stream. Simi- 
larly, if the request data stream includes the plurality of 
scripts, a file name of the script to be executed first should 
have been specified as the file name to be executed first in 
the request data stream. In other words, the request data 
stream sent from the client includes the executing instruction 
for the command or the script to be executed first. This 
condition makes it possible to regard the executing instruc- 
tion as being fetched from the request data stream and 
registered in the job queue. 

[0059] FIG. 11 illustrates a processing routine (a portion) 
of the execution managing unit 924 in the server 920. At 



first, at a step 1101, the execution managing unit 924 fetches, 
from the job queue 923, a job to be executed next. The 
judgement as to which job is the job to be executed next is 
based on specification of the OS (operating system). Next, at 
a step 1102, the job thus fetched is passed to the executing 
unit 925 so as to be executed. If the fetched job is an 
executing instruction for executing one command alone, it is 
sufficient to execute the one command. If the fetched job is 
an executing instruction for executing one script, the one 
script is executed. When a plurality of scripts are being sent, 
the main script is executed. Although there are some cases 
where, during the execution of the main script, a lower-order 
script is called and executed. In such a case, the necessary 
script is fetched from the script file storing unit 926 so as to 
be executed since, by the processing in FIG. 10, all the 
scripts have beea stored already in the script file storing unit 
926. 

[0060] Next, at a step 1103, it is awaited for the execution 
of the script (at the time of executing a command, the 
command) to be terminated. After the termination, at a step 
1104, the termination state is recorded (by the executing unit 
925, actually) into the execution-result storing unit 927 as a 
log, thereby completing the processing. Examples of the 
information recorded as the log are job names, script names, 
result file names, and so on. The result file name is the name 
of a result file created for each of the commands (at the time 
of executing the script, each of the commands executed in 
the script) executed at the step 1102. Each of the commands 
is executed, thereby creating the result file in the name that 
is unique to the command and storing the result file into the 
execution-result storing unit 927. Consequently, in the case 
where a plurality of commands are executed by the execu- 
tion of the script (Usually, one script includes a plurality of 
commands), the result files for the respective commands are 
created. 

[0061] As having been described above, the registration 
and the execution of the batch job are performed. The client 
910 further includes the state display unit 913, which makes 
it possible to perform the job -information acquisition (GET) 
concerning a registered job. Namely, in FIG. 9, in accor- 
dance with, for example, an instruction from the user, the 
state display unit 913 issues, to the request analyzing unit 
921 in the server 920, a request for the job -information 
acquisition (GET) for inquiring in what state the registered 
job lies at present. The request for the job-information 
acquisition (GET) includes information such as a job name 
for identifying the object job the job information of which 
will be acquired. The request analyzing unit 921 passes, to 
the execution managing unit 924, the information such as the 
job name for identifying the job the job-information acqui- 
sition of which has been requested, thus instructing the 
job-information acquisition. 

[0062] FIG. 12 illustrates the procedure of the job-infor- 
mation GET processing. The execution managing unit 924 
in the server 920 performs the job-information GET pro- 
cessing in accordance with the instruction passed from the 
request analyzing unit 921. At a step 1201, by referring to 
the job queue 923, it is judged whether or not a specified job 
exists within the job queue 923. If the specified job exists 
within the job queue 923, it means that, at present, the job 
is awaiting the execution or is in the course of the execution. 
Accordingly, the state where the job lies is returned back to 
the state display unit 913 in the client 910 of the request 
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issue source. If the specified job does not exist within the job 
queue 923, it means that the execution has been terminated 
already. Accordingly, by referring to the log stored in the 
execution-result storing unit 927, information to be returned 
back of the content of the log is summarized as the response 
data, then being returned back to the state display unit 913. 

[0063] In particular, in this embodiment, the plurality of 
result files are stored into the execution-result storing unit 
927 by executing the plurality of scripts. Consequently, in 
the job-information acquisition (GET), it is made possible to 
summarize and return the plurality of result files back to the 
client. Namely, when the request for the job-information 
acquisition (GET) is issued from the state display unit 913 
in the client 910 in FIG. 9, a plurality of names of the result 
files that are wished to be returned back are specified within 
the request. At a step 1203, the execution managing unit 924 
collects the plurality of result files with those specified 
names and creates the response data stream (FIG. 6) includ- 
ing the content of those result files, then returning the 
response data stream back to the state display unit 913 in the 
client 910 in the communication sequence as explained in 
FIGS. 2 and 4. 

[0064] Incidentally, in order to create the response data 
stream including the content of the plurality of result files 
and send the response data stream to the state display unit 
913 in the client 910, the execution managing unit 924 in the 
server 920 has the function of creating the response data 
stream including the content of the plurality of result files. 
Moreover, in order to reproduce the plurality of result files 
at the state display unit 913, the state display unit 913 in the 
client 910 has the function of reproducing the plurality of 
result files from within the received response data stream. 
Concretely, in much the same way as the one in which the 
request data stream is created that includes the content of the 
plurality of script files as explained in FIG. 5, by doing the 
following, the execution managing unit 924 creates a 
response data stream including the content of the result files 
of arbitrary numbers: With a tag for making a declaration 
that a result file will be sent, the declaration is made, and 
with a tag for, specifying the result file name, the result file 
name is specified, and with a tag for specifying the number 
of lines, the number of lines of the result file is specified. 
After that, the contents of the result files are enumerated, and 
with SUBSET-END, the end of the result files is specified, 
and the above-mentioned portion ranging from the specifi- 
cation of the result file name to SUBSET-END is repeated. 
Also, in much the same way as the one in which, in FIG. 10, 
the plurality of scripts are extracted and reproduced as the 
files each, the state display unit 913 that has received such 
a response data stream reproduces the plurality of result files 
from within the response data stream. 

[0065] FIG. 13 illustrates an example of a job registration 
screen in the client 910. The user has created in advance the 
script files testOl.jcl and test01.jcl2, using the text editor or 
the like. When registering a job, the user instructs the screen 
in FIG. 13 to be displayed and checks "specify"1302 in 
script transfer definition 1301, thereby being able to specify 
the script transfer. In a script file specification region 1303, 
it is possible to describe a plurality of script files to be 
transferred to the server. It is also possible to specify a script 
file to be executed first of the plurality of script files. In FIG. 
13, as the script file to be executed first, the test01.jcl2 is 
described in being surrounded by a rectangular frame within 



the specification region 1303. Various types of information 
is set on the screen in FIG. 13 and an acknowledge button 
1304 is switched on. This operation causes, for example, the 
qsub command explained in FIG. 8C, to be inputted into the 
command analyzing unit 911 in FIG. 9, thereby making it 
possible to perform the job registration including the plu- 
rality of scripts as is described above. 

[0066] FIG. 14 illustrates an example of the job state 
display displayed by the state display unit 913 in the client 
910 in FIG. 9. The state display unit 913 issues the request 
for the job -information acquisition (GET) with a predeter- 
mined time interval and acquires the present state of a job 
and the result file as is described earlier, then displaying 
them in a list as illustrated in FIG. 14. The reference 
numerals denote the following, respectively. 1401 sequential 
number of the job, 1402 a display for indicating that the 
present state of the job is "during execution", 1403 job name 
of the job, 1404 name of a script file included in the job. 
When a plurality of script files are included in the job, names 
of all the plurality of script files (in FIG. 14, scripta and 
scriptb) are displayed. The reference numerals further 
denote the following: 1405 a display of "termination" for 
indicating that a job Job2 has already been in the termination 
state, 1406 file name of a result file received from the server 
as a result of the termination of the job Job2. When a 
plurality of result files (in FIGS. 14, A, B, and C) are 
received, names of all the result files are displayed. 

[0067] Incidentally, in the above-mentioned embodiment, 
the explanation has been given concerning the example 
where the job is registered from the client to the server. 
Taking advantage of the above -described protocol, however, 
allows the plurality of scripts to be transferred in much the 
same way even when the job is registered and executed from 
a server to another server. In the UNIX, it is usual that the 
job transfer is performed between the server/server so as to 
disperse the load. Consequently, it turns out that, naturally, 
the job registration from the UNIX-based client to another 
server is once performed by way of a server existing on the 
side of the client through a network. In that case, the 
communication taking advantage of the above-described 
protocol is executed between the server/server. 

[0068] According to the embodiment explained so far, the 
data stream in the plain text is used as the job transfer 
protocol. This condition makes the implementation easy, not 
depending on the types of the network. Also, the various 
types of parameters are specified in the plain text by the 
expression using the tags. This condition makes it easy to 
extend the protocol. Even when the protocol has been 
extended and the types of the tags are increased in a 
higher-order version, a lower-order version system ignores a 
tag that it does not recognize, thereby making it possible to 
establish the mutual interconnection between the systems 
the versions of which are different to each other. Also, it is 
possible to implement the user interface and the implement- 
ing method with different kinds of variations in correspon- 
dence with the circumstances of the system. 

1. A job transferring method of sending a request from a 
first computer to a second computer so as to cause said 
second computer to register and execute a job, wherein a 
plurality of scripts are included in said request, said script 
being an aggregation of a plurality of commands. 
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2. A job transferring method of sending a request from a 
first computer to a second computer so as to cause a job to 
be registered and executed, comprising the steps of: 

creating, by said first computer, a request data stream 
including content of a plurality of scripts, and 

sending, by the first computer, said created request data 
stream from said first computer to said second com- 
puter. 

3. A job transferring method of sending a request from a 
first computer to a second computer so as to cause a job to 
be registered and executed, comprising the steps of: 

receiving, by said second computer, a request data stream 
sent from said first computer, said request data stream 
including content of a plurality of scripts, 

extracting, by said second computer, said content of said 
plurality of scripts in said received request data stream 
and storing said content of said plurality of scripts as a 
script file for each script, and 

executing, by said second computer, a script to be 
executed first of said plurality of scripts. 

4. A job transferring method of sending a request from a 
first computer to a second computer so as to cause a job to 
be registered and executed, comprising the steps of: 

creating, by said first computer, a request data stream 
including content of a plurality of scripts, 

sending said created request data stream from said first 
computer to said second computer, 

extracting, by said second computer, said content of said 
plurality of scripts in said request data stream and 
storing said content of said plurality of scripts as a 
script file for each script, and 

executing, by said second computer, a script to be 
executed first of said plurality of scripts. 

5. A job transferring method of sending a request from a 
first computer to a second computer so as to cause a job to 
be registered and executed, comprising the steps of: 

creating, by said first computer, a request data stream, said 
request data stream including content of a plurality of 
scripts and an executing instruction for a script to be 
executed first of said plurality of scripts, 

sending said created request data stream from said first 
computer to said second computer, 

extracting, by said second computer, said content of said 
plurality of scripts in said request data stream and 
storing said content of said plurality of scripts as a 
script file for each script, and 

fetching and executing, by said second computer, said 
executing instruction for said script to be executed first, 
said executing instruction being included in said 
request data stream. 

6. The job transferring method as claimed in claim 1, 
wherein a data stream of said request is a text data-formatted 
stream and, utilizing a predetermined tag, describes various 
types of parameter information. 

7. Hie job transferring method as claimed in claim 5, 
wherein said request data stream is a text data- formatted 
stream and, utilizing a predetermined tag, describes various 
types of parameter information. 



8. A job transferring method of sending a request from a 
first computer to a second computer so as to cause a job to 
be registered and executed, comprising the steps of: 

summarizing content of a plurality of result files into one 
response data stream including said content of said 
plurality of result files, said plurality of result files 
being created as a result of executing said job by said 
second computer, and 

sending said response data stream from said second 
computer to said first computer. 

9. The job transferring method as claimed in claim 8, 
further comprising a step of extracting, by said first com- 
puter, said content of said plurality of result files included in 
said response data stream and storing said content of said 
plurality of result files for each result file. 

10. The job transferring method as claimed in claim 9, 
wherein said response data stream is a text data-formatted 
stream. 

11. A job transferring system, comprising: 

a first computer for sending a second computer a request 
for causing a job to be registered and executed, and 

said second computer for receiving said request sent from 
said first computer so as to register and execute said job 
in accordance with said request, wherein a plurality of 
scripts are included in said request, said script being an 
aggregation of a plurality of commands. 

12. A job transfer source computer as a first computer in 
a job transferring system that includes said first computer for 
sending a second computer a request for causing a job to be 
registered and executed and said second computer for 
receiving said request sent from said first computer so as to 
register and execute said job in accordance with said request, 
said first computer of said job transfer source comprising: 

means for creating a request data stream including content 
of a plurality of scripts, and 

means for sending said created request data stream to said 
second computer. 

13. A job transfer target computer as a second computer 
in a job transferring system that includes a first computer for 
sending said second computer a request for causing a job to 
be registered and executed and said second computer for 
receiving said request sent from said first computer so as to 
register and execute said job in accordance with said request, 
said second computer of said job transfer target comprising: 

means for receiving a request data stream sent from said 
first computer, said request data stream including con- 
tent of a plurality of scripts, 

means for extracting said content of said plurality of 
scripts included in said received request data stream 
and storing said content of said plurality of scripts as a 
script file for each script, and 

means for executing a script to be executed first of said 
plurality of scripts. 

14. A job transferring system, comprising: 

a first computer for sending a second computer a request 
for causing a job to be registered and executed, and 

said second computer for receiving said request sent from 
said first computer so as to register and execute said job 
in accordance with said request, wherein 
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said first computer comprises means for creating a 
request data stream including content of a plurality 
of scripts, and means for sending said created request 
data stream from said first computer to said second 
computer, and 

said second computer comprises means for extracting 
said content of said plurality of scripts included in 
said request data stream and storing said content of 
said plurality of scripts as a script file for each script, 
and means for executing a script to be executed first 
of said plurality of scripts. 

15. A job transferring system, comprising: 

a first computer for sending a second computer a request 
for causing a job to be registered and executed, and 

said second computer for receiving said request sent from 
said first computer so as to register and execute said job 
in accordance with said request, wherein 

said first computer comprises means for creating a 
request data stream, said request data stream includ- 
ing content of a plurality of scripts and an executing 
instruction for a script to be executed first of said 
plurality of scripts, and means for sending said 
created request data stream from said first computer 
to said second computer, and 

said second computer comprises means for extracting 
said content of said plurality of scripts included in 
said request data stream and storing said content of 
said plurality of scripts as a script file for each script, 
and means for fetching and executing said executing 
instruction for said script to be executed first, said 
executing instruction being included in said request 
data stream. 

16. The job transferring system as claimed in claim 11, 
wherein a data stream of said request is a text data-formatted 
stream and, utilizing a predetermined tag, describes various 
types of parameter information. 

17. The job transferring system as claimed in claim 15, 
wherein said request data stream is a text data-formatted 



stream and, utilizing a predetermined tag, describes various 
types of parameter information. 

18. A job transferring system, comprising: 

a first computer for sending a second computer a request 
for causing a job to be registered and executed, and 

said second computer for receiving said request sent from 
said first computer so as to register and execute said job 
in accordance with said request, wherein said second 
computer comprises means for creating a response data 
stream including content of a plurality of result files, 
said plurality of result files being created as a result of 
executing said job, and means for sending said created 
response data stream from said second computer to said 
first computer. 

19. The job transferring system as claimed in claim 18, 
wherein said first computer comprises means for extracting 
said content of said plurality of result files included in said 
response data stream and storing said content of said plu- 
rality of result files for each result file. 

20. The job transferring system as claimed in claim 19, 
wherein said response data stream is a text data-formatted 
stream. 

21. The Job transferring method as claimed in claim 2, 
wherein said first computer inputs a job parameter definition 
file and creates said request data stream in accordance with 
content of said job parameter definition file, said job param- 
eter definition file including the number of script files 
transferred, names of said script files transferred, and a name 
of a script file to be executed first. 

22. The job transfer source as said first computer as 
claimed in claim 12, wherein said first computer inputs a job 
parameter definition file and creates said request data stream 
in accordance with content of said job parameter definition 
file, said job parameter definition file including the number 
of script files transferred, names of said script files trans- 
ferred, and a name of a script file to be executed first. 

***** 
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